Stage 3: Migration Process
Use these commands and scripts to complete the migration process.
- If you are upgrading from - 2019.x.xrun the following scripts. If not, go to Step 2.- 🛑 Later versions (2020.1.x and higher) do not require this first step. - JobsAndTasksmigration script- # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine # npm run migrate
- JobsFrom20193migration script- ⚠ This script aids in migrating any active running jobs between major versions for certain scenarios. If proper procedure is followed and all jobs are paused, canceled, or completed, this script is optional. - # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine/migration_scripts # node migrateJobsFrom20193.js
- normalizeGroupsscript (2019.3 and higher)- # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine # npm run normalizeGroups
- migration_scriptsunder Configuration Manager- ⚠ This script upgrades all the old Golden Configs to Jinja2 Templates. If you have any Golden Configs at all and you are upgrading from - 2019.xto- 2020.2.x and higher, then this script is required.- # cd /opt/pronghorn/current/node_modules/@itential/app-configuration_manager/migration_scripts # node migrate_to_jinja.js
 
- Run the following for Tags. - # cd /opt/pronghorn/current/node_modules/@itential/tags/migration_scripts # node migrateTagRefs.js
- Audit (confirm) all Template Builder security dependencies ( - chroot,- sudo,- ldd) are installed and tested. These security dependencies are required for Template Builder to execute Jinja2 templates in a contained context.- ⚠ For more information, see Template Builder Dependencies in the IAP Installation guide. - Install the shell utilities. - yum -y install sudo chroot ldd
- Verify the user that is used to run the server (usually - pronghorn) is permitted to run- sudo chrootwithout a password prompt. An example command which accomplishes this is shown below, but the system admin is expected to tailor this command to their environment. As long as the server is permitted to run- chrootthrough- sudowithout a password prompt, Template Builder can sandbox Jinja2 template execution.- echo "pronghorn ALL=(ALL) NOPASSWD: $(command -v chroot)" >> /etc/sudoers
- Make sure Template Builder is permitted to copy in all dependencies required by Python. These dependencies are the output of the - lddcommand, as well as all paths in Python's internal- sys.pathconstant. If file permissions prevent Template Builder from copying these files into its- chrootjail directory, Python will not be able to execute within the sandbox subshell and Template Builder will execute in an insecure mode.
- Verify IAP is running and examine the logs. 
- Template Builder will report that it is creating a sandbox directory for Jinja2 template execution, and when it is finished, it will report either success or failure. 
- Once Template Builder has finished initializing the sandbox directory, run a Jinja2 template. 
- Examine the server logs and look to make sure there are no warnings stating that Jinja2 execution is running in an insecure mode. 
 
- Run index validation and confirm the latest indexing metrics. - Login to IAP and confirm you are able to view job details in the Active Jobs / Completed Jobs / Cancelled Jobs tabs from the Job Manager page. - ⚠ If there are no job details and you get a Run Indexing Alert, resolve using the links below. - How To Fix Indexing For - Target Release 2020.1.x / 2020.2.x - Target Release 2021.1.x - Figure 4: Job Manager Indexing Alert  
 
- Navigate to the Job Details page in IAP to update and migrate jobs. - This step uses a Just-in-Time (JIT)/ OnDemand migration strategy, which puts job migration into the - getJobDetailsAPI. This means whenever a user displays the Job Details page, job migration occurs only when needed.
- Confirm the Start Date, End Date and Assignee details are updated. - Figure 5: JIT OnDemand job Migration  
 
Next Step
Go to Stage 4: Post-Migration to confirm all jobs have migrated.